The workplace continues to move at an increasingly faster pace requiring real-time response and access, as well as secure text messaging. Smartphones can help bridge the technology gap for mobile employees as well as those that are just away from their desk or need to respond after-hours.
Traditional Mobile Notification services depends heavily on the carrier, and hence often hit by the carrier coverage limitations, and their communication cost. More over these notification solutions provide basic (rudimentary) functions with severe lacking in support for content security, content type, and content size. Also there are no or limited two-way workflow support. Along with that, the communication is not real-time, and often unreliable.
Many applications, including public safety and disaster recovery, require rapid response, often to tens of thousands of recipients across a broad spectrum of different carriers. Currently, no products are available to provide the necessary speed and accuracy, along with desirable customer and company benefits. Current products require multiple servers with large amounts of memory and storage. Not only does this increase the cost to the customer it adds to the customer support challenges.
Blackberry Mobile App—Development in BB10 Platform
The Blackberry 10 platform poses a number of issues around the platform's capability, support and APIs. The background processes, unlike other platforms, are developed separately from the user interface (UI) front end, but said processes need to be paired with the front end UI in a single distribution application package, and there are limitations on rendering the UI in the background app. Other challenges lie in the notification limitations between the background app and the front end app.
The BB10 client/app could be written in the C++ native platform to get the most of the BB10 APIs and features. But this choice raises certain issues, due to Blackberry's own rapidly changing APIs. One solution would be a pair of apps, comprising a front end UI app, and a background headless app. However, there are many uncertainties in communication between these two sub apps. In light of all the BB10 challenges and limitations, the app for the BB10 platform could be designed to be functionally equivalent to the native iOS™ app. Such an app would comprise different self-managed modules that can be used either in the background or foreground app, depending on the needs of the future BB10 releases. The background app could be just an augmentation of these modules, with each module using observer design patterns to send events to others. Hence the BB10 app would simply become an assembly of functional independent modules as objects that interact with others to exchange events, data, or information. Moreover, the design would use local TCP/IP sockets to implement two-way communication pathways between the sub app, thus enabling smooth asynchronous and sync-based communication channels. Thus this system would be a full messaging solution that provides support for BB10 devices. Most current systems do not support the BB10 platform simply due to its challenges and limitations, and in the others that do provides support, the apps are functionally very thin.
Next Generation UI Backend Architecture
Future solutions could be based on a true Model View Controller design pattern, with the backend composed of only web services. This approach moves on from old CGI, FastCGI backend-engines to more scalable backend platform which is web services. These web services are RESTful APIs that would be called by the frontend UI to perform any action or fetch data items. The front end would be a single page web app, with all the panels loaded dynamically, removing the page loading phenomena from the whole UI. The front end logic engine should be based on the latest, widely used JAVASCRIPT™ framework called Backbone.js, with other UI frameworks. With this design, the front end could be completely decoupled from the back end. Thus with this architecture, developers could easily change the UI theme without making any change to the back end, and vice versa, enabling UI changes more easily and with least efforts. Most current products use old Java or .Net based web UI frameworks that do not scale well with the number of users/usage, and they are not very efficient. Using C/C++ as the language and Axis2/C as the web service engine lets developers build the most fastest and most efficient back end. Also, other functions such as lazy loading, and smart URLs increases the efficiency of the whole web UI.
Dialer Service Multi-Threaded Design with Minimum Critical Sections
The speed and accuracy of reaching recipients with voice messages is essential to any mission-critical communication platform. Execution of these requirements without the overhead and complexity of dozens of costly parallel applications calls for a proprietary methodology and coding scheme. The dialer service should be a multi-thread service that comprises threads for reading jobs, preparing jobs for calls, dispatching jobs, setting up their calls, receiving call progress statuses, and making updates to the job description in the database. All these threads could share data in between, and thus logically require a locking mechanism to ensure data does not get corrupted due to simultaneous access. Locking (implementing critical sections), however, introduces a lot of inter-thread waiting, making the overall processing (divided among threads) slower. The dialer service should have data structures and code that enable simultaneous access with minimum requirements for critical sections, or with critical sections with minimum length. This approach would enable distributed voice calling processes in multiple threads with very minimum overhead.
What is needed is a product to meet customer requirements by using a small server with a consumer grade processor, a gigabyte of storage and less than 8 gigabytes of memory. Additionally needed is an application developed in different self-managed modules, so they could be used either in the background or foreground, depending on the needs of the future BB10 releases. The background app could be an augmentation of these modules, with each module using observer design pattern to send events to others. This design strategy would enable development with no loss of time due to changing platform.